-
Notifications
You must be signed in to change notification settings - Fork 649
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: opt-out ssm parameters for github app #4335
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@AppliNH thx for the contribution.
Supporting external maanaged ssm parameters is fine. A view things to consider are
- Update docs see docs dir to explain the usages
- Explain or express via an example how to ajust the policies so the lambda can access the secrets. Lambda roles are exported.
- I have added a comment related to the variables you introduces. I think it can done in a single app variable. Which avoid the introdduction of new variables. It also makes it easier to validat the variable.
…+ remove unused variables
Hi 👋 Really sorry for the delay, I've been terribly busy. I've updated everything, let me know what you think of it! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am busy with the review. I am fine with the approach. Please can you update the docs as well, see this page: https://github-aws-runners.github.io/terraform-aws-github-runner/configuration/ I think we should add this as major configuration choice. and / or make a remark in the ssm paramater section.
Please can you also make a note that the provided value has preference ofer the ssm paramater, at least this is the current order in reading the values via the terraform function coalense
I have tested th default example (with pool). Need to test the added example and the multi runners as well.
@npalm Right now it's
|
Would keep the order in this way |
@AppliNH I think we are all most done. I have tested the relevant examples and the newly added example. Also made some changes directly to the PR. Let me know what you think. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reviewed and tested it all again, LGTM!
It's provisioned in production for us 👌
🤖 I have created a release *beep* *boop* --- ## [6.3.0](v6.2.3...v6.3.0) (2025-02-24) ### Features * opt-out ssm parameters for github app ([#4335](#4335)) ([a2f013f](a2f013f)) @AppliNH ### Bug Fixes * **lambda:** bump the aws group in /lambdas with 6 updates ([#4440](#4440)) ([b10d87e](b10d87e)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: runners-releaser[bot] <194412594+runners-releaser[bot]@users.noreply.github.com>
Hi! 👋
Throughout my recent experiences, we had strong requirements to not have secret values in the state. To handle that, I suggest to make optional the creation of SSM parameters as part of the regular flow so it doesn't leak secrets in Terraform state.
We could alternatively use the latest
ephemeral
feature, but I'm not sure everyone is using Terraform 1.10+ atm since it's quite recent. I also think relying on ephemerals should be part of a new breaking release as it won't be compatible with Terraform < 1.10.Let me know what you think of this!